In addition to today's over-the-top (“OTT”) and traditional telecommunication service verticals provided by mobile operators, 5G systems are expected to support emerging use cases with specific and sometimes critical Quality of Service (“QoS”) requirements such as Internet of Things (“IoT”) (including mission critical mobile-to-mobile (“M2M”)), vehicle-to-vehicle/-infrastructure (V2X) communication, tactile Internet (such as remote factory/robotics control or augmented reality), smart buildings, sensor networks, etc.
OTT applications generate the dominant share of today's mobile broadband traffic and are expected to continue as a major use case in the 5G era as well. Popular applications include web browsing, video streaming (e.g., YouTube, Netflix, Hulu, etc.), navigation (e.g., Waze, Google Maps, etc.), social sites (e.g., Facebook, etc.), OTT real time voice/video (e.g., Skype, Viber, WhatsApp, etc.), instant messaging, gaming, productivity, etc. The OTT applications have highly dynamic traffic profiles and as such may establish many flows per application with short lifetime and wide service boundary. Accordingly, their QoS/QoE requirements (e.g., throughput intensive, low latency, etc.) may vary highly, with orders of magnitude differences between the amount of bandwidth required for good QoE per application session. Each application session is unique, thus the required QoE may also depend on the way the user behaves and/or interacts with the application. Therefore, predefined QoE requirements are only partly applicable. That is, the session specific QoE requirements should be created according to the actual context using the predefined high level requirements defined by the operator.
The QoS architecture of the current mobile networks (3G, Wideband Code Division Multiple Access (“WCDMA”)/High Speed Packet Access (“HSPA”), Long Term Evolution (“LTE”), LTE Advanced (“LTE-A”) have been designed without the capability of fulfilling the above expectations for OTT applications or the emerging service verticals.
On the one hand, the QoS architecture is radio centric with enforcement points located at the Radio Access Network (“RAN”) (e.g., LTE eNB or 3G RNC/BTS). This was based on the assumption that the capacity of the radio access is limited compared to the mobile backhaul transport network thus packet queuing and resource management (that defines the QoS) happens in the RAN.
In contrast, the policy framework is placed in the core (based around the Policy and Charging Rules Function (“PCRF”)/Policy and Charging Enforcement Function (“PCEF”) elements) with the purpose of enforcing subscriber specific limitations and subscription boundaries irrespective of the available resources and congestion status either at the RAN or on the mobile backhaul (“MBH”). Application awareness within policies is limited and mostly applied for content filtering (e.g., parental control) or coarse throttling of specific user plane flows.
Initially, the policy framework has lacked both the insight (QoE, congestion status, flows sharing the same resources) and the apparatus (context based resource management and application scheduling) required for dynamic QoS/QoE enforcement. Lately, the UPCON (i.e. the IEEE Uttar Pradesh Section Conference on Electrical, Computer and Electronics) activity has been established to import congestion awareness to the policy framework via proprietary signaling from the RAN to the PCRF that enables the enforcement of congestion based rules. Still, this signaling is non-real time (i.e., enforcement may miss the critical time window for meaningful actions) as well as lacks context information (congested resource and UE level status) required for dynamically calculated QoE friendly actions. Therefore, the UPCON congestion information acts yet another dynamic trigger for statically defined rules valid during congestion.